home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930026.txt < prev    next >
Internet Message Format  |  1994-06-04  |  11KB
  1. Date: Tue, 26 Jan 93 04:30:17 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #26
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Tue, 26 Jan 93       Volume 93 : Issue   26
  11.  
  12. Today's Topics:
  13.                            BCC 3.1 (2 msgs)
  14.                               if netmask
  15.                        Micor Radios and 9600B.
  16.             N6GN Microwave Link Construction Inf (2 msgs)
  17.                              nos futures
  18.                        TCP-Group Digest V93 #22
  19.                         wampes & SVR4 (2 msgs)
  20.  
  21. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  22. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  23. Problems you can't solve otherwise to brian@ucsd.edu.
  24.  
  25. Archives of past issues of the TCP-Group Digest are available
  26. (by FTP only) from UCSD.Edu in directory "mailarchives".
  27.  
  28. We trust that readers are intelligent enough to realize that all text
  29. herein consists of personal comments and does not represent the official
  30. policies or positions of any party.  Your mileage may vary.  So there.
  31. ----------------------------------------------------------------------
  32.  
  33. Date: Mon, 25 Jan 93 10:39:15 EST
  34. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  35. Subject: BCC 3.1
  36. To: nos-bbs@hydra.carleton.CA
  37.  
  38. WOW! that is my impression of the BC 3.1 compile vs. 2.0 - I just
  39. started using it. The same compile on 3.1 yielded a 217K compressed
  40. exe vs. 218K using BC 2.0 BUT the running size seems to run consistently
  41. 15-20K smaller (more core available) and the speed is noticeably faster.
  42. Domain lookups from ramdisk etc. - I would highly recommend this update
  43. for those that are having memory problems. I am using the -1 option in
  44. both compiles.
  45.  
  46. Now I would like to make the necessary changes to use the -3 option. I
  47. sent a note to Phil asking for the required changes - can anyone fill
  48. me in on this?
  49.  
  50. Doug
  51.  
  52. ------------------------------
  53.  
  54. Date: Mon, 25 Jan 93 22:45:26 -0800
  55. From: karn@qualcomm.com (Phil Karn)
  56. Subject: BCC 3.1
  57. To: crompton@NADC.NAVY.MIL, nos-bbs@hydra.carleton.CA
  58.  
  59. Doug,
  60.  
  61. I must have missed your note in the flood (I automatically sort my
  62. incoming mail, and anything that has "tcp-group" in it will
  63. automatically be filed in that category even if it also mentions
  64. "karn". And I don't read tcp-group very often since it seems to be
  65. almost entirely about bulletin boards instead of TCP/IP these days.
  66.  
  67. Anyway, my most recent versions of NOS already support the Borland -3
  68. option. The only real changes were in the .s files, as the interrupt
  69. handlers have to save the 32-bit versions of the general registers.  I
  70. did make a change to the pktdrvr.c file only because of the way it
  71. hooks to assembler. The code shrinks another 30K or so when you use
  72. -3.
  73.  
  74. Phil
  75.  
  76. ------------------------------
  77.  
  78. Date: Thu, 21 Jan 93 20:56:45 PST
  79. From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
  80. Subject: if netmask
  81. To: A.D.S.Benham@bnr.co.uk
  82.  
  83. > Date: Thu, 21 Jan 93 13:16:15 GMT
  84. >
  85. > I'm puzzled by the "if netmask ..." command in, well, every NOS I've looked at.
  86. >                     ^^
  87. >                  (that's as in interface)
  88.  
  89. The 'if' is abbreviated from 'ifconfig' (InterFace CONFIGuration).
  90. I never abbreviated it to 'if', always used at least 'ifc'.
  91.  
  92. > The AUTOEXEC.NOS file I have been using for several years has in it
  93. > if netmask tnc0 0x44ffffff
  94. > which can't possibly be right (?) as the ampr.org domain is decimal 44
  95. > (hexadecimal 2C).
  96. > I've tried "if netmask tnc0 0x2cffffff" and also "if netmask tnc0 0x2c000000"
  97. > which I found in someone else's AUTOEXEC.NOS file. I've not seen anything
  98. > different happening.
  99.  
  100. I (and my colleages) use it to tell NOS how much bits are used for
  101. network part of address, for example in network on Physics Department
  102. (fuw.edu.pl) we use addresses 148.81.4.1 to 148.81.7.254 (..4.0 and
  103. .7.255 are Internet broadcast addresses) and netmask is 0xfffffc00 -
  104. this tells NOS low 10 bits are used to select computer on local net
  105. if high 22 match our network.   73's, JT
  106.  
  107. ------------------------------
  108.  
  109. Date: Mon, 25 Jan 93 06:45:51 -0800
  110. From: "Dana H. Myers" <dana@phad.la.locus.com>
  111. Subject: Micor Radios and 9600B.
  112. To: kf5mg@vnet.ibm.com, TCP-Group@ucsd.edu
  113.  
  114. > 
  115. > Sorry for the off the topic post. If there's a better place, please
  116. > flame me and let me know. I've got a chance to pick up some VHF MICOR
  117. > radios for $40 each. ( Control head $10 more ) Can these run 9600b
  118. > and is this a good price? ( What's a control head? ) Send answers to
  119. > kf5mg@vnet.ibm.com. unless you feel others would be interested in
  120. > your info. Thanks. Also need any 9600B mods for an IC-245.
  121. > 
  122.  
  123.  
  124. I haven't tried it, but I know for a fact that VHF Micors, normally
  125. phase modulated, may be frequency modulated by replacing the "3 pin"
  126. channel elements with a "4 pin" transmit channel element.  The 4 pin
  127. elements are used in the DPL equipped Micors, and should be easy to
  128. retrofit to a non-DPL Micor.  I think Brian Kantor, brian@ucsd.edu,
  129. has done something like this.  I'm not certain how much useful deviation
  130. you get with this approach....
  131.  
  132. Dana  KK6JQ
  133. dana@locus.com
  134.  
  135. ------------------------------
  136.  
  137. Date: Mon, 25 Jan 93 08:51:39 -0600
  138. From: sbrown@charon.dseg.ti.com (Steve Brown)
  139. Subject: N6GN Microwave Link Construction Inf
  140. To: Steve_Wright@kcbbs.gen.nz
  141.  
  142. Steve Wright - ZL1BHD  writes:
  143.  
  144. >ARRRRGGGGGGHHHHH!!!!   **WHY** isn't there a newsgroup for this subject ?  
  145. >,
  146. >.
  147. >.
  148. >rec.radio.amateur.packet.rf
  149.  
  150. I second the emotion.
  151.   
  152.               *********************************************
  153.               |  Steve Brown, WD5HCY         | Simplicate |
  154.               |  sbrown@charon.dseg.ti.com   | and add    |
  155.               |  wd5hcy@kf5mg.#dfw.tx.usa.na | lightness. |
  156.               *********************************************
  157.  
  158. ------------------------------
  159.  
  160. Date: Mon, 25 Jan 93 22:32:39 HST
  161. From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
  162. Subject: N6GN Microwave Link Construction Inf
  163. To: sbrown@charon.dseg.ti.com (Steve Brown)
  164.  
  165. > 
  166. > Steve Wright - ZL1BHD  writes:
  167. > 
  168. > >ARRRRGGGGGGHHHHH!!!!   **WHY** isn't there a newsgroup for this subject ?  
  169. > >,
  170. > >.
  171. > >.
  172. > >rec.radio.amateur.packet.rf
  173. > 
  174. > I second the emotion.
  175. >   
  176. >               *********************************************
  177. >               |  Steve Brown, WD5HCY         | Simplicate |
  178. >               |  sbrown@charon.dseg.ti.com   | and add    |
  179. >               |  wd5hcy@kf5mg.#dfw.tx.usa.na | lightness. |
  180. >               *********************************************
  181. > 
  182.  
  183. There was a high-speed modem mailing list at one time but I haven't seen
  184. anything come out of it in a long time.
  185.  
  186. Tony
  187.  
  188. ------------------------------
  189.  
  190. Date: Mon, 25 Jan 93 11:58:17 EST
  191. From: kz1f@RELAY.WESTBORO.LEGENT.COM
  192. Subject: nos futures
  193. To: Richard.Elling@eng.auburn.edu, tcp-group@ucsd.edu, kz1f@LEGENT.COM
  194.  
  195. Dick Elling writes:
  196.  
  197. > Walt>   Not really, the mail envelope would be dropped on the host it was
  198. > destined to.
  199. > Walt>   The object, envelope, would know how to get there, ie smtp.
  200.  
  201. > I'm not convinced this is a scalable solution.  It might be fine if there
  202. > were at most a dozen or so hosts.  But with the internet gateways we've
  203. > already passed that size.  Also, I think this is the wrong object to
  204. > interface with for mail.  Mail should do to people or robots.  ftp should
  205. > go to hosts.
  206.  
  207. Well effectively what you say is correct. The model I was using was that an 
  208. individual really only has a handful of hosts he deals with. ie, I connect to 
  209. giskard, Hobbes, Watson, UCSD. In this environment I would have a managable
  210. folder, dropping a mail msg on UCSD would initiate an immediate smtp. Leaving 
  211. it in a "mailbox" would hold it until there was a pass thru to pick up pending 
  212. mail. Dblclking on watson would open a folder of, in OS/2 parlence, WPSfile 
  213. objects. The reason I commented on Jacks remark abt SOM was that that leaves
  214. people with the impression that I am proposing a single vendor solution, thats 
  215. incorrect, I am proposing a stylistic solution, not a vendor one. To the extent
  216. it will use SOM or WPS or C++ is almost academic, it could use dos windows or
  217. NT/Cairo objects. In a word, its style and usability I am addressing more than
  218. OS. After all, the OS only exists to provide the services and support the
  219. overlying application needs. NOS, as we know it today has been pushing on the
  220. limits of DOS for some time. Walt
  221.  
  222. Walt Corey - kz1f@kz1f.legent.com
  223. ----------------------------------
  224. |                                |
  225. | Space for Rent apply within    |
  226. |                                |
  227. ----------------------------------
  228.  
  229. ------------------------------
  230.  
  231. Date: Mon, 25 Jan 93 16:38:28 eut
  232. From: hcoste@thomson-sctf.fr ()
  233. Subject: TCP-Group Digest V93 #22
  234. To: TCP-Group@ucsd.edu
  235.  
  236.  [A.?
  237. >
  238.  
  239. ------------------------------
  240.  
  241. Date: Mon, 25 Jan 93 8:11:56 CST
  242. From: dave@holl.com (David Vrona)
  243. Subject: wampes & SVR4
  244. To: TCP-Group@UCSD.Edu
  245.  
  246. Hi all,
  247.  
  248. I've been trying to compile wampes-921129 (latest I think) on my 386 running
  249. Dell SVR4 v2.2.  Most everything compiles except login.c.
  250.  
  251. Has anybody had success compiling wampes on a SYSV box???
  252.  
  253. Here is the problem output:
  254.  
  255. > 
  256. >  gcc -O -s -DUNIX -DSYS5 -DFD_SETSIZE=1024 -c login.c
  257. > login.c: In function `login_open':
  258. > login.c:492: structure has no member named `ut_host'
  259. > login.c:492: structure has no member named `ut_host'
  260. > login.c: In function `login_close':
  261. > login.c:545: structure has no member named `ut_host'
  262. > *** Error code 1 (bu21) (ignored)
  263. > 
  264.  
  265. thanks
  266. --
  267.  David Vrona N9QNZ               +1 708 680 2829 (voice)               
  268.  Hollister Incorporated          +1 708 680 2123 (fax)                 
  269.  2000 Hollister Drive            Internet: dave@hp1.holl.com           
  270.  Libertyville, IL  60048-3781    UUCP: {well connected}!ddsw1!hp1!dave 
  271.  Opinions expressed are my own and not those of Hollister Incorporated.
  272.  
  273. ------------------------------
  274.  
  275. Date: Tue, 26 Jan 1993 10:12:56 +0000 (GMT)
  276. From: kelvin@thed.uk22.bull.com (Kelvin J. Hill)
  277. Subject: wampes & SVR4
  278. To: dave@holl.com (David Vrona)
  279.  
  280. The ut_host field for some reason is not implemented on a number of systems
  281. and the only solution is to #ifdef the code that uses it and remove it from
  282. your version. I've had the same problem when compiling up other bits of
  283. networking code. If you can, it may be worth using a dummy value to replace
  284. the info that you would have obtained from this field.
  285.  
  286. Kelvin.   (G1EMM)
  287.  
  288. ------------------------------
  289.  
  290. End of TCP-Group Digest V93 #26
  291. ******************************
  292. ******************************
  293.